I use libg++ exactly for the usefulness you mentioned.
I also use another C++ lib called LEDA for efficient graph implementation.
The third thing is using NeXTstep for display purposes.
The interaction was pretty neat, concerning, that I could send C++ classes/objects
around with objective-C calls!
The whole package does Object recognition with DSP for feature extraction/convolution
stuff and an elastic matching/neural net approach for the recognition back end
for research purposes.
Distributed Objects on the other side like NeXT has them now should be much easier
in Objective-C. Was there discussion about this point also?
But the mixed approach depends a lot on what your compiler can do!
I just sent a mail this afternoon to next-prog concerning NeXTs broken cc++ compiler.
Later,
Martin
From: Steve_Naroff@next.com (Steve Naroff)
Date: Tue, 8 Sep 92 14:06:18 -0700
To: gsk@gnu.ai.mit.edu
Subject: Re: development priorities, beta testing
Cc: snaroff@next.com
> If we can make Objective-C and C++ operate together, we can leverage off of things like libg++ and Interviews, which already exist as free software.
We have done this...it has been shipping since NeXTSTEP version 2.0. Our goal was to allow developers with an existing base of C++ code to use it with NeXTSTEP's Objective-C based kits/tools. The problem we have had is keeping up with the rapidly changing (and often buggy) g++ compiler, given the limited resources we place on C++ at NeXT. Is this product what you mean when you say "operate together"? Nevertheless, we recently finished merging the latest version of Objective-C with the g++ in GCC version 2.2.2. I hope this work can be reused!
snaroff.
From: Steve_Naroff@next.com (Steve Naroff)
Date: Tue, 8 Sep 92 16:19:16 -0700
To: gsk@marble.com
Subject: Re: C++ and Objective-C; coding from interface specs
Cc: snaroff@next.com
Status: RO
> What people want is to message C++ from Objective-C, and vice versa. Is this what your changes do?
Yes. Simply stated, it replaces the ANSI-C layer with C++. Since Objective-C tries hard to "stay out of C's way", this works out quite nicely. See /NextDeveloper/Examples/AppKit/CalculatorLab++ if you are interested in a small example of what I am talking about.
> If NeXT is making life easier for C++ programmers, a lot of people will be pleased. I remember that at NeXTWORLD Expo, the attitude was, paraphrasing, "we've put C++ support in there, but we haven't made it very easy, because basically we don't think people should be wasting their time with C++." I remember thinking that I too did not care much for C++, however those who did would interpret such remarks as "NeXT is being arrogant again, they love to go their own way.
We did this to make life easier for folks who already have an investment in C++. We are not religious about "C++ vs. Objective-C"...we would like the 2 languages to coexist as much as possible. C++ is, however a 2nd class citizen in NeXTSTEP...given our heritage, limited resources, and the complexity of C++, we continue to focus on support for Objective-C. If we were being "arrogant", we would not have ported g++ and merged it with Objective-C. Oh well...I guess people love to throw stones!.
On the legal side, I believe re-engineering a class (from an interface spec) is kosher...in fact, we (i.e. NeXT) would like the FSF runtime to be modeled after our API, so that port headbutts are minimized. For example, objc_getClass("NXFoobar") will hopefully exist...I would hope the name and type signitures for common runtime hooks are maintained. I will verify this with NeXT lawyers.
snaroff.
From: Steve_Naroff@next.com (Steve Naroff)
Date: Wed, 9 Sep 92 13:56:59 -0700
To: jr@alpo.media.com (J.R. Jesson)
Subject: Re: Your mission, should you choose to accept it. . .
We released the source prior to shipping NeXTSTEP 3.0, a vast improvement over release 2.0 (thanks to M Carling at BaNG).
The compiler is based on GCC 1.93, the debugger is based on gdb 3.95.
We have integrated our latest version of Objective-C (with protocol support) with GCC 2.2.2...this is close to what we will ship with NeXTSTEP 486.
NeXT is happy to provide these mods so that they can be integrated into the GNU source tree.
snaroff.
From: Steve_Naroff@next.com (Steve Naroff)
Date: Wed, 9 Sep 92 15:27:08 -0700
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Your mission, should you choose to accept it. . .
Here are some brief answers to questions raised in response to my previous email...
> Where are the modifications?
The mods are in the NeXT source tree...I would like to hand this work off to the appropriate person asap. This person (to be named by Geoffrey S. Knauth) would be responsible for integrating this work into the FSF source tree...we could help if problems arise. Objective-C++ support has been integrated as well.
> When and where can I get the integrated version?
>From FSF, once the previous work is complete...this should happen before we ship NeXTSTEP 486. Once the 486 product ships, you can get an updated version of the BaNG source disk from NeXT.
> Does this mean that NeXTStep '486 will ship with a compiler based on GCC 2.2.2? How about the debugger?
NeXTSTEP 486 wil ship with GCC 2.2.2 (or later, depending on our schedule and the quality of GCC 2.2.2). We have no plans to upgrade the debugger at this time.
> If so, will an update to 3.0 be released at the same time?
The GNU sources will be released coincident with NeXTSTEP 486.
> Do you know anything about the Music Kit release?
The Music Kit is unbundled in Release 3.0...see the release notes for more info.
> Will the GNU source and Music Kit stuff be available for FTP from
Next?
Not that I am aware of...
snaroff.
From: athan@object.com (Andrew Athan)
To: gnu-objc@prep.ai.mit.edu
Subject: C++ wrappers
One problem with wrapping C++ is taking care of the semantics (constructor/destructor, method parameter polymorphism, etc.)
Efficiency is less of a problem. Even the simplest wrappers
@implementation FooWrapper
{
Foo f;
}
- objcFooMethod:(int)x
{
f.method(x);
}
@end
etc. are still only going to be 1 method call more time consuming than using the C++ object as is and only 1 function call more time consuming than using a straight objc class. One can also build an objc Class object using the runtime functions for the C++ class where the extra function call time would be completely avoided (though the runtime would have to be able to avoid passing the SEL hidden parameter).
Just to play devil's advocate: Can someone justify for me the need to do this at all, since one of the goals is the ability to call C++ as part of objective-C code. Yes, one has to learn yet-another-syntax, but ...
Thanks...I couldn't agree more. btw, the Objective-C++ work we did is very straightforward...the goal is to enable programmers to use objects developed in both languages within the same source module (without cumbersome "wrappers"). The philosophy is simple, C++ should be as convenient to use from Objective-C as ANSI-C is. This makes it really easy to use C++ libraries from Objective-C, which is an important goal. For example, C++ objects can be "a-part-of" (i.e. reference) Objective-C objects (and vice-versa). However C++ objects can NOT inherit from Objective-C objects (and vice-versa)...I thought this was strange, hard to solve, and not so useful.
Since both languages have very different goals (C++ a "better C"...Objective-C a "thin Smalltalk veneer"), there were very few syntactic or semantic ambiquities. Both languages retain their native syntax/semantics and performance characteristics. You could imagine unifying the object models, however we made no attempt to do this (it wasn't clear that this was a worthwhile goal).
snaroff.
Date: Sat, 12 Sep 92 05:56:49 EDT
From: jjobe@mrj.com (jason jobe)
To: gnu-objc@prep.ai.mit.edu
Subject: Objc++
As indicated in previous mail one of the objectives is to make it easy to
work with both ObjC and C++. In line with that:
1) Some talk about ObjC class wrappers for C++ Classes. Is the real goal
to be able to use the same method calling syntax for both? ie given
a C++ construct "foo->draw (myCanvas);" should "[foo draw:myCanvas];"
be permitted/encouraged/supported. If so, is it a straight translation or
do we have some different dispatcher for C++ methods calls or something.
2) Does one want more runtime info about C++ classes? If so, what?
I seem to recall something along these lines discussed in the context
of InterViews (from Stanford).
I also have some other questions/comments:
1) If protocols use versions (a good idea) could one cleanly indicate
compatabilty between different versions? For example,
@protocol <Foo1>
- draw;
- erase;
@end
and
@protocol <Foo2>
- draw;
- erase;
- cache;
@end
Can Foo2 subsume Foo1? If I conformTo Foo2 then I also conformTo Foo1. Should
this be ok?
2) Can/will dynamically loadable objects be supported on other platforms?
3) What about some standard way resolve name space conflicts between
lib sets? Say I have 3 different "List" classes, how can I mix and match?
Do I, as a lib builder always have to prepend my intiails or something
ridiculous like that? InterViews had some work around but this seems worth
supporting.
I rather like the idea of ObjC++. This should be fun.
Jason
Date: Fri, 28 Aug 92 10:44 EDT
From: <MKK2@psuvm.psu.edu>
Subject: Re: objc wrappers about c++
To: gsk@marble.com
I didn't mean that wrappers around C++ was the ideal approach. I meant
that it might be a good initial step. 1. create the wrappers. This gets
people something they can use. 2a. Rewrite the most often used ones
in ObjC. 2b. Create a tool that will take a C++ class an automagically
create a wrapper for it. 3. Based on 2a, create a tool that translates
C++ into ObjC.
You can start with 2a, instead, but it'll be a much longer wait before
that's not as simple to read, but then you should have defined it as an ObjC
class, if you wanted that.
|> 4) Routing C++ method calls through an Objc-like dispatcher WHEN DESIRED.
Sounds good to me. How would you denote when to dispatch or not.
|> Other Questions/Issues raised:
|>
|> 1) How should operator overloading be applied to Objc classes?
a) answer = [array operator+: another]; ?
I think this should be (close to) the internal representation
whether we allow the syntactic sugar of
b) answer = array + another;
is another question.
|> 2) Are we going to add the static object instantiation that NeXT left out?
If you want a Cpp2ObjC "processor" then this will be needed. (I think)
|> 3) Should we try to provide method name overloading
|> (based on argument types) for Objc methods?
Hmm, that would be interesting.
|>
|>
|> Hopefully this will get the ball rolling.
roll, roll
|>
|> Jason
|> jjobe@mrj.com
|> GNU Objc ObjC++ Manager
|>
Bill Shirley
shirley@fdr.jsc.nasa.gov
Date: Mon, 28 Sep 92 23:14:05 EDT
From: jjobe@mrj.com (jason jobe)
To: gnu-objc@prep.ai.mit.edu
Subject: Objective-C + C++ -> ObjC++
Jason queries:
[ stuff deleted ]
> 1) How should operator overloading be applied to Objc classes?
IMHO, this is not an extraordinary added value. I would say, just make sure that overloaded operators continue to work in a C++ context, but don't support them for Objective-C objects.
> 2) Are we going to add the static object instantiation that NeXT left out?
PLEASE! More specifically, _automatic_ object instantiation, so that I can declare an object at the top of my method/function and have it automagically freed when I return from my method/function.
I WOULD CALL THIS A HUGE WIN.
> 3) Should we try to provide method name overloading (based on argument
> types) for Objc methods?
Absolutely. To tell you the truth, _I_ might only use it once in a blue moon, but its availability doesn't get in my way (if my style dictates no overloading, I just won't write overloaded methods). Maybe have a special syntax for declaring overloadable parameters and return values? I'm putting on my asbestos suit now . . . . 8')
Ta-ta,
- Kurt
Kurt Starsinic # kstar@medequity.com
Director of Systems # (NeXTmail preferred)
MedEquity, Inc. #
555 North Lane, Suite 6183 # (215) 397-0201 voice
Conshohocken, PA 19428 # 397-0203 fax
The opinions expressed by me just might be those of MedEquity, Inc.
"There is nothing in the world that will take
the chip off one's shoulder like a feeling of success."
- Thomas Wolfe
Date: Mon, 28 Sep 92 23:14:05 EDT
From: jjobe@mrj.com (jason jobe)
To: gnu-objc@prep.ai.mit.edu
Subject: Objective-C + C++ -> ObjC++
Volunteers needed.
To recap:
COMMUNICATIONS BETWEEN OBJECTIVE-C AND C++
Make the Objective-C library and libg++ help each other;
investigate language enhancements to make this easy.
As the ObjC++ manager I thought throw out some ideas of my own.
(Please beware of my own NeXT bias)
To me this suggest several things:
1 ) We want to make it easy to equate Objc and C++ class structures.
2) We clearly need more info on C++ classes at runtime. I seem to recall
some sort of "dossier" being suggested in the context of Stanford's InterViews
(anybody know about this?).
3) Perhaps one should encourage consistent message syntax.
Can/should "[graphic draw]" be equivalent to "graphic->draw()" ?
If so, what about "[canvas draw:graphic at:point]" vs.
"canvas->drawAt (graphic, point)"
4) Routing C++ method calls through an Objc-like dispatcher WHEN DESIRED.
Other Questions/Issues raised:
1) How should operator overloading be applied to Objc classes?
2) Are we going to add the static object instantiation that NeXT left out?
3) Should we try to provide method name overloading (based on argument types)
for Objc methods?
Hopefully this will get the ball rolling.
Jason
jjobe@mrj.com
GNU Objc ObjC++ Manager
From: Geoffrey S. Knauth <gsk>
Date: Tue, 29 Sep 92 11:28:22 -0400
To: gsk
Subject: [MKK2@psuvm.psu.edu: Re: Objective-C + C++ -> ObjC++]
>1 ) We want to make it easy to equate Objc and C++ class structures.
One way to do this is to automate the process. If one has C++ classes, but
wants to live in an Obj-C world, there should be a filter that reads the
C++ interface and outputs an Obj-C wrapper for it. Pascal to C exists,
why not C++ to Obj-C and vice versa? (It's easy for me to suggest this
because I have absolutely no qualifications to actually do it 8-) 8-)
>3) Should we try to provide method name overloading (based on argument types)
> for Objc methods?
The math major lurking in my youth has always regretted this design decision
of Objective-C. Surely, a function is both a name *and* a domain *and* a
range. So I vote YES to name overloading based on argument and return value
types. Again, I'm safe from ever being asked to implement this, at least by
people who actually want to see it done.
However, I don't think extending the language is our real mission here.
Working implementation first, redesign the language later.
>Hopefully this will get the ball rolling.
>Jason
>jjobe@mrj.com
>GNU Objc ObjC++ Manager
Date: Tue, 29 Sep 92 11:03:01 -0500
From: Gregory B. Lampshire <gbol@geol.vt.edu>
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Objective-C + C++ -> ObjC++
Reply-To: gbol@rglnext.geol.vt.edu
I am confused about operator overloading, C++ and ObjC. I am not a compiler guy so correct me if I am wrong.
As long as the overloaded operator occured in [object msg: (arg)] construct it would be easy to add operator overloading in a small way in that 'msg' is just a string which gets looked up in a table at run time to decide which function to call (the function name itself doesn't have to be change to some mangled name if one assumes that the declaration for the selector "msg" only takes one type of arg). It shouldn't be that difficult to get rid of the ":" after the method name as long as one assumes that it is a binary message with only one selector and one argument.
Such a scheme is not difficult to add to ObjC.
What would be more difficult is to add it such that the example below would work. Then each selector "msg" has to be mangled such that the msg name and type of arguments were reflected in the final function call and so that not just binary operators could be easily used.
This is much more difficult.
I take it the discussion is about the second way and not about the first limited way.
Is this right? I have done alot of Smalltalk programming and would like to see the second way but realize that it is quite a stretch for the current compiler.
//----------an example---------------
#import <objc/Object.h>
@interface MyClass: Object
{
int nInt;
float nFloat;
}
- add: (int) a;
- add: (float) a;
- + (int) a;
- + (float) a;
@end
@implementation MyClass
- add: (int) a
{
printf("blah int\n");
return self;
}
- add: (float) a
{
printf("blah float\n");
return self;
}
- + (float) a
{
printf("blah float +\n");
return self;
}
- + (int) a
{
printf("blah int +\n");
return self;
}
@end
int main()
{
id aMyClass;
aMyClass = [[MyClass new] init];
[aMyClass add: 2];
[aMyClass add: 3.3];
[aMyClass + 2];
[aMyClass + 3.3];
}
Date: Tue, 29 Sep 1992 11:30:54 EDT
From: gdb0@lehigh.edu (GLENN BLANK)
Subject: Re: Objective-C + C++ -> ObjC++
To: shirley@gothamcity.jsc.nasa.gov (Bill Shirley [CSC])
Cc: gnu-objc@prep.ai.mit.edu
>|> COMMUNICATIONS BETWEEN OBJECTIVE-C AND C++
>
>(Knowing Xlib, Xt, and NeXTSTEP)
>I found Interviews obtuse and contrived, even the simplest programs were
>difficult to make run. Most of the examples they included with the
>release would randomly dump core, with no explanation. I don't know
>if I was working with an earlier flawwed product or if it has improved.
>
My experience with Interviews echos yours. It is also difficult to
combine with other libraries. I would not like to see Interviews
endorsed by association with gcc. Imitating smalltalk's treatment
of user interface facilties
> Bill Shirley
> shirley@fdr.jsc.nasa.gov
>
From: billb@jupiter.fnbc.com (Bill Burcham)
Date: Tue, 29 Sep 92 11:52:27 -0500
To: gnu-objc@prep.ai.mit.edu
Subject: Objective-C + C++ -> ObjC++
> Begin forwarded message:
>
> Date: Tue, 29 Sep 92 10:09:20 -0400
> From: Kurt D. Starsinic <kstar@medequity.com>
> To: gnu-objc@prep.ai.mit.edu
> Subject: Re: Objective-C + C++ -> ObjC++
> Reply-To: kurt@medequity.com
>
> Begin forwarded message:
> From: jjobe@mrj.com (jason jobe)
> Jason queries:
>
> [ stuff deleted ]
>
> > 1) How should operator overloading be applied to Objc classes?
>
> IMHO, this is not an extraordinary added value. I would
> say, just make sure that overloaded operators continue
> to work in a C++ context, but don't support them for
> Objective-C objects.
>
(McMahon on) YES, YOU ARE CORRECT SIR! (McMahon off)
One way to do this is to automate the process. If one has C++ classes, but
wants to live in an Obj-C world, there should be a filter that reads the
C++ interface and outputs an Obj-C wrapper for it. Pascal to C exists,
why not C++ to Obj-C and vice versa? (It's easy for me to suggest this
because I have absolutely no qualifications to actually do it 8-) 8-)
-----
I am working on a parser that does ObjC->C++. The parsing is completed. Most of the conversion is also done. I'll put it on the archives soon.
Ciao,
Imran
From: Steve_Naroff@next.com (Steve Naroff)
Date: Tue, 29 Sep 92 11:13:42 -0700
To: jjobe@mrj.com (jason jobe)
Subject: Re: Objective-C + C++ -> ObjC++
Cc: gnu-objc@prep.ai.mit.edu
If the goal is to improve communication between Objective-C and C++ class libraries, why don't you just use the Objective-C++ compiler developed by NeXT.
Objective-C++ accomplishes your stated goal. It enables programmers to use objects developed in both languages within the same source module (without cumbersome "wrappers"). The philosophy is simple, C++ should be as convenient to use from Objective-C as ANSI-C is. This makes it really easy to use C++ libraries from Objective-C, which is an important goal. For example, C++ objects can be "a-part-of" (i.e. reference) Objective-C objects (and vice-versa). However C++ objects can NOT inherit from Objective-C objects (and vice-versa)...I thought this was strange, hard to solve, and not so useful.
Since both languages have very different goals (C++ a "better C"...Objective-C a "thin Smalltalk veneer"), there were very few syntactic or semantic ambiguities. Both languages retain their native syntax/semantics and performance characteristics. You could imagine unifying the object models, however we made no attempt to do this. It wasn't clear that "unifying the object models" is what developers wanted.
It just struck me that our high level goals are very similar, yet there is much discussion about adding language features that are orthogonal to improved communication between ObjC/C++. For example, adding overloading to Objective-C may be a worthwhile feature, however it has very little to do with improved communication.
I am not assuming that NeXT Objective-C++ will solve the group's problems, I just want to understand your goals for the project.
If the goals are fuzzy, Objective-C will start approaching the complexity of C++, which I know is bad. Extending C++ also seems like a loosing proposition...isn't the popularity of C++ mostly due to its portability?
snaroff.
Date: Tue, 29 Sep 92 15:24:00 -0400
From: rms@gnu.ai.mit.edu (Richard Stallman)
To: Steve_Naroff@next.com
Cc: jjobe@mrj.com, gnu-objc@prep.ai.mit.edu
Subject: Objective-C + C++ -> ObjC++
It would seem that Objective C++ would allow Objective C programs to
use C++ library classes, by means of C++ constructs.
That is useful, but I think what most Objective C programmers want is
to be able to use those library classes by means of Objective C
constructs only. Does Objective C++ make this possible?
> Objective-C and C++ class libraries, why don't you just
> use the Objective-C++ compiler developed by NeXT.
>
I'm doing a lot of work with this now. There are some problems but they are tool bugs (compiler, gdb, DBKit header file decls, etc). My c++ objects call ObjC objects, ObjC objects call c++ objects. It works well.
One problem though is that I can't encapsulate c++ objects in a ObjC class decl. The c++ objects must be pointers instantiated using 'new' in the ObjC designated initializer. Complain. Complain.
-dpg
From: billb@jupiter.fnbc.com (Bill Burcham)
Date: Wed, 30 Sep 92 09:26:59 -0500
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Objective-C + C++ -> ObjC++
Cc: ssircar@canon.com (Subrata Sircar)
Subrata Sircar <ssircar@canon.com> writes:
> Kurt D. Starsinic <kstar@medequity.com> writes:
> ! PLEASE! More specifically, _automatic_ object
> ! instantiation, so that I can declare an object at the top
> ! of my method/function and have it automagically freed when
> ! I return from my method/function. I WOULD CALL THIS A HUGE
> ! WIN.
>
> This would be nice - objects as automatic function/method variables.
>
NeXT Object class provides allocFromZone:. I think an allocFromAutomatic would be an elegant approach. allocFromAutomatic would use alloca() (see MALLOC(3)) to allocate memory from the stack.
>NeXT Object class provides allocFromZone:. I think an allocFromAutomatic >would be an elegant approach. allocFromAutomatic would use alloca() (see >MALLOC(3)) to allocate memory from the stack.
This would solve the problem only in the case of objects that do not have out-of-line storage associated with them. E.g.,
@interface MyString:Object
{
char *theBuffer;
}
@end
would end up leaving whatever "theBuffer" points to unfreed on function return.
The "problem" with automatic object allocation is that it introduces the need for constructor & destructor syntax/semantics.
Andrew Athan
Objective Technologies, Inc.
From: MKK2@psuvm.psu.edu
Date: Wed, 30 Sep 92 14:35 EDT
Subject: Re: Objective-C + C++ -> ObjC++
To: gnu-objc@prep.ai.mit.edu
>That is useful, but I think what most Objective C programmers want is
>to be able to use those library classes by means of Objective C
>constructs only. Does Objective C++ make this possible?
Not by magic. Basically, there are so few syntax clashes between C++
and Objective-C that the OC user can just include C++ when appropriate.
To disguise C++ as Objective-C, a wrapper can be used. Just create
an Objective-C class that has one instance variable, an instance of the
C++ class. Then add an OC method for each of the C++ methods that you
want to appear in the interface (or perhaps internally). Those methods just
call the appropriate C++ method.
Note that this approach allows later subclassing og the OC class.
Disclaimer: I've thought about this, but I've never actually done it.
I could be missing a big gotcha here. Naroff? What do you say?
This version of "using a wrapper" is something I'd like to see
automated. Perhaps a filter could read C++ the Foo.h file for class Foo
in C++, and spit out a Foo.[hm] in Obj-C that offers access to C++
classes as if they were Obj-C classes. Of course, a filter that goes the
other way would be great for C++ programmers, but this is the GNU Objective-C
project now, isn't it. 8-)
I am not a compiler-knowlegeable person, so I have no idea of the ins and
outs of integrating Obj-C and C++ transparently. This wrapper solution
appeals to the old Unix spirit of solving 70% of the problem with 20%
of the work, adding another little tool to the tollkit, and getting back
to work.
Lastly, I want to make an editorial comment: In my opinion, this group
should steer away from inventing a new language, at least for now. Let's
get a working Objective-C out the door, with enough tools and class
libraries that people will be inclined to use it.
Lee Sailer
GNU Objective-C Class Library Map Manager
Date: Wed, 30 Sep 92 09:28:38 -0700
From: Dennis Glatting <seattle-ni-srvr!dglattin@trirex.com>
To: uunet!gothamcity.jsc.nasa.gov!shirley@uunet.uu.net (Bill Shirley [CSC])
Subject: Objective-C + C++ -> ObjC++
Cc: gnu-objc@prep.ai.mit.edu
> |> 4) Routing C++ method calls through an Objc-like
> dispatcher WHEN DESIRED.
>
>
> Sounds good to me. How would you denote when to dispatch or not.
>
If you chose to not go thru the dispatcher then how are you going to
handle posing and inheritance? Perhaps my question should be: What
does WHEN DESIRED mean? Perhaps an example would be useful.
-dpg
Date: Thu, 1 Oct 92 23:18:21 EDT
From: jjobe@mrj.com (jason jobe)
To: gnu-objc@prep.ai.mit.edu
Subject: ObjC++ direction
Although not directly related our objectives I would also like to ask/propose
the following: How about providing some scoping syntax (maybe a precompiler
hack) to help resolve name space problems with regard to Class names.
InterViews used macros with some automated preporcessing to prepend every
class name with "iv". This works ok but I think some standard mechanism
should be provided. How should I specify which "List" implementation I want
to use from which library?
And now to business.
I appreciate all the input for ObjC++. While this effort will hopefully
lead to new and interesting language features we need to pick a few
objectives to focus on initially. Also, lets get something out the door
that works and optimize later.
Here's the gist:
1) The primary focus is on the ObjC programmer.
2) Minimize linguistic changes.
3) Some sort ObjC class should "wrap" around a C++ one. This process
should be maximaly automated.
4) Some runtime information about desired C++ classes should be provided.
Something needs to be provided for dynamic method dispatching.
This seems useful and desired by many respondents.
5) Forget (for now) such desirables as overloading anything in ObjC.
Although I think C++ should recognize "id" and ObjC class pointers so
C++ operator overloading could be applied to ObjC objects. NOTE: If this
becomes to complicated then skip it.
Example:
int operator+ (id objcObject, int x) {
int y = [objcObject integerValue];
return (x + y);
}
This may be a non-issue. I have yet to try it.
Problems seem to revolve around the appropriate control over
construction/destruction and initialization of C++ objects.
Questions:
1) Should a central dispatcher be provided for calling C++ methods
or should we go for simple inline wrappers that make the C++ object
"look" like an ObjcC one?
2) Should there be a real ObjC class which stands in for its C++
counterpart? (I think so. Perhaps a new base class ObjectPlus.)
These excerpts sum it it well.
(Richard Stallman):
Using Objective C objects from C++ is a completely different problem.
I suggest separating the two problems. The more important one is
using C++ objects from Objective C...
(Richard Stallman):
I like the idea of a tool to write a program that gets added to the
application to enable it to use a particular C++ class.
(Steve Naroff)
An interesting project from my perspective is "Dynamic C++", which is
merely C++ with a rich runtime model (like Objective-C). This would
add very little syntax to C++. It means adding the notion of a
dynamic type to C++ (like "id", which is a "void *" for objects).
Sending messages to an object of anonymous type would have the same
semantics as Objective-C.
ObjC++ compiler hackers wanted. Lots of fun but no money.
Call Jason for a good time (jjobe@mrj.com)
Regards,
Jason
From: MKK2@psuvm.psu.edu
Date: Fri, 2 Oct 92 17:10 EDT
Subject: Re: ObjC++ direction
To: gnu-objc@prep.ai.mit.edu
>Here's the gist:
>1) The primary focus is on the ObjC programmer.
Yes, but I'd say the primary focus is on making GNU ObjC as usable as GNU
c++.
>2) Minimize linguistic changes.
Agreed. A sure way to go astray is to invent a new language without
meaning to. 8-)
>3) Some sort ObjC class should "wrap" around a C++ one. This process
> should be maximaly automated.
Yes. The Map Team is going to look at doing this by hand for a while, so
we'll be able to recommend what needs to be automated. I might add that,
as soon as useful ObjC classes appear which are of use to C++ programmers,
then C++ wrappers for the ObjC classes will be needed. As efficiency
issues become important, wrappers can be transparently replaced by native
implementations.
>4) Some runtime information about desired C++ classes should be provided.
> Something needs to be provided for dynamic method dispatching.
> This seems useful and desired by many respondents.
Maybe, but only so long as it doesn't add features that aren't available
from other good C++ compilers. That is, we don't want to redefine either
language.
>5) Forget (for now) such desirables as overloading anything in ObjC.
> Although I think C++ should recognize "id" and ObjC class pointers so
> C++ operator overloading could be applied to ObjC objects. NOTE: If this
> becomes to complicated then skip it.
> Example:
> int operator+ (id objcObject, int x) {
> int y = [objcObject integerValue];
> return (x + y);
> }
> This may be a non-issue. I have yet to try it.
This is a language change. I'm not against new languages--far
from it--and I think there are folks here who are qualified to design
(ObjC++)++, but as you said at the top, first things first.
